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Title: MULTI-DIMENSIONAL ACCOUNTING ENGINE 

CROSS-REFERENCE TO RELATED APPLICATIONS 

Not Applicable. 

BACKGROUND-FIELD OF INVENTION 

This invention relates to general accounting principles and computer software. 
It will most likely be classified in Class 705, in either Subclass 10 or Subclass 30. 

BACKGROUND-DESCRIPTION OF PRIOR ART 

Various accounting software applications have been developed and marketed. 
However, all of these applications have followed the conventional model that has 
dominated the accoxmting profession for over five-hxmdred years. According to 
that model, each business transaction is recorded in three different places. The 
transaction is entered once in a journal (an historical record of all transactions) 
and then it is entered in two accounts in the general ledger. In one of the general 
ledger accounts it is recorded as. a debit and in the second general ledger accoxmt 
it is recorded as a credit. The accounts in the general ledger are then treated as 
the primary source of transaction information in accounting, with the journal 
being used primarily as a backup to the general ledger accounts. 

The Multi-dimensional Accounting Engine takes a revolutionary new approach 
to accounting. It treats the journal itself as the sole source of information for 
generating accounting reports and does not even enter the information in general 
ledger accounts. It treats the general ledger as a useless vestige of the "paper and 
pencil" days and recognizes that it serves no usefiil purpose in electronic data 



processing. 



In the conventional accounting practice, the general ledger accounts serve the 
purpose of categorizing the business transaction. In the Multi-dimensional 
Accounting Engine this categorization is performed through the dimensions in the 
imderlying multi-dimensional data structure. A dimension in a computer data 
structure is an index that is used to access a piece of data. In a single dimension 
data structure an index of 4 accesses the fourth element in the rov^ that makes up 
the single dimension. In a two dimensional data structure, the row index of 6 and 
the column index of 8 accesses the eighth element of the sixth row in the two 
dimensions that make up the data structure. Any number of dimensions can be 
given to the data. In the Multi-dimensional Account Engine, the fimction 
performed by the ledger accoxmts is satisfied by dimensions. Each transaction has 
a debit dimension, a credit dimension, a calendar date dimension, and a 
description dimension, as well as any number of other dimensions that the 
business uses to categorize the transaction. 

This revolutionary multi-dimensional approach to accounting makes the Mulit- 
dimensional Accounting Engine a unique invention that has no precedent in the 
business world. 

A database search of the United States Patents was made and a large number 
of U.S. patents were analyzed. No patent was found that conflicted with the 
current invention. The following is a list of those patents that had something in 
common with the current invention, although none of these patents approximated 
the intent, scope and purposes of the current invention: 

1 . Patent No. 5,974,396 entitled, "Method and system for gathering and 
analyzing consumer purchasing information based on product and 
consumer clustering relationships". This invention is a system for tracking 
the buying habits of consumers and creating direct advertisements that are 
sent to individual consxmiers based on the consumers* past purchases. A 
database is used to store information on the consumers and each consimier 
is associated with at least one product cluster. Specific consumers are then 
targeted according to the cluster information. Although this invention 
provides the user with an analysis of consumer information, it performs this 
fimction by clustering data. The Multi-dimensional Accounting Engine 
provides this analytical information by "slicing" or combining the data along 



one or more of the data's many dimensions. Furthermore, the Multi- 
dimensional Accounting Engine is primarily intended for joumaling 
accounting transactions and its ability to analyze customer behavior is 
ancillary to its primary function. 

2. Patent No. 5,740,427 entitled, "Modular automated account maintenance 
system". An accounting system that is directed towards small businesses. 
The system processes predefined business transactions. Each transaction 
contains a core part and an auxiliary part. The core part defines a specific 
accounting process and the auxiliary part contains data specific to the 
transaction. The two parts are assigned the same unique identifier number 
and then stored in two different storage mediums. Any transaction can then 
be retrieved and reassembled using the unique identifier number. The core 
part defines which accounts are affected by the transaction and generates 
updates to those accoimts. In actuality, this patent has nothing in common 
with the Multi-dimensional Accounting Engine other than the feet that it is 
a tool used for the accounting practice. It does not use a multi-dimensional 
data structure and so does not use the analytical powers of dimensional 
slicing in order to dynamically generate the accounting reports. 

3. Patent No. 5,875,435 entitled, "Automated accoxmting system". A business 
accounting system that allows transactions to be input at various remote 
locations and fiirther allows access to the system by an agent of the 
business, such as an accoxmtant, who is also at a remote location. The 
system provides a menu of financial transactions and itemization codes to 
facilitate the input of data. The system is used to prepare and print inpome, 
expense, assets and liability statements. Again, this patent only relates to 
the Multi-dimensional Accounting Engine in that they both are used for 
accounting purposes and generate accounting reports. It does not use the 
mxilti-dimensional data structure that the Multi-dimensional Accounting 
Engine does and does not offer the analytical power that the Multi- 
dimensional Accounting Engine does in generating accounting reports and 
other information creating reports. 

4. Patent No. 6,026,397 entitled, "Data analysis system and method", A 
customer analysis system that assigns customers to demographic groups 
according to similar characteristics. The demographic groups are analyzed 
to predict customer behavior based upon past customer behavior, product 



preference, and propensity to respond to direct mailings 
SUMMARY 

In accordance with the present invention a complete accounting system can be 
managed by a single software engine that accepts business transactions and 
produces, at the user's request, all of the standard accounting reports. The 
accounting reports are produced from an underlying data structure that 
categorizes data in any number of dimensions. Each dimension represents a 
different way of categorizing the transaction. Implicit in this model are the four 
dimensions necessary for the accounting process, the debit dimension, the credit 
dimension, the calendar date dimension, and the description dimension. 

OBJECTS AND ADVANTAGES 

The objects and advantages of the present invention are: 

1 . All the accounting and bookkeeping functions of a business are reduced to 
the minimal eflfort of simply recording each business transaction. Once the 
business transaction is recorded in the engine, all the accounting reports are 
performed automatically using the multi-dimensional aspects of the stored 
data. 

2. The Multi-dimensional Accounting Engine can be configured to maintain 
any number of additional dimensions besides the standard accounting 
dimensions of the debit account, the credit accoimt, and the time. Each 
additional dimension offers the business a different way to categorize the 
business transactions for the purpose of market analysis, expense tracking, 
and other interesting ways of forming information. 

3. Accounting reports can be dynamically generated as needed, rather than 
periodicaUy (e.g., quarterly income statements). Furthermore, the user can 
specify the range of time used in the analysis (e.g., an income statement can 
be generated for the time frame of Jime 15, 2001 to July 20, 2001). 

4. Since general ledger accoimts do not have any real existence in the Multi- 
dimensional Accounting Engine there is no duplication of data, a practice 
that is inherently dangerous and causes information systems to become 
inconsistent and conflicting. It is important to note that general ledger 
accounts can be generated dynamically as reports if the user desires them). 



Because of the additional power that the multi-dimensional data model lends 
to the practice of accounting, the Multi-dimensional Accounting Engine can 
provide businesses with the analytical power to maintain inventory, design market 
approaches and predict fiiture earnings in addition to what is currently 
accon^lished by existing accounting paradigms. 

DESCRIPTION - MAIN EMBODIMENT 

The main embodiment of the present invention is illustrated in Figures Al and 
A2. Figure Al introduces the concept of a multi-dimensional data structure to the 
reader. It is this data structure that lies at the heart of the invention and therefore 
should be understood clearly by the reader. Figure A2 is the real static description 
of the Multi-dimensional Accounting Engine. 

Figure Al is a diagram of a typical multi-dimensional data structure. If 
implemented in a realtional database each box in the figure would be a table (the 
multi-dimensional data structure can be in:^)lemented in another form other than a 
relational database). 

The primary characteristic of the design in Figure Al is its "star" shape. This is 
referred to as a "star schema". There is typically a single table in the center, 
referred to as a "fact" table, surrounded by a number of dimensional tables. In 
Figure Al, the fact table is represented by the box number 2. The dimension 
tables are represented by the boxes numbered 6, 8, 10, 12, 14, and 16. Each 
record in the fact table contains one or more amount fields (e.g., the amount of 
the business transaction) and a reference (or index) to a record in each of the 
dimension tables. A record in the fact table may have an amount of one-hundred 
dollars and an index to the record in the credit dimension that represents the 
"Cash" account and an index to a record in the debit dimension that represents the 
"Office Furniture" account. Further indexes in the fact record would reference 
records in the remaining dimension tables. Groups of the dimensions can be used 
in combination with each other to categorize the transactions in the fact table. 

Figure A2 is an illustration of the static specification of this invention. Each 
box in Figure A2 is a software component representing one or more objects, in 
the inventions object-oriented architecture. Each component is named and 
numbered and given a short description. 



Central to Figure A2 is the component named the Dimensional Transformer 
(numbered 100 in figure A2). This component converts conventional, non- 
dimensional data, typical of accounting journal entries, into data that has 
dimensions and is ready to be loaded into the underlying multi-dimensional data 
structure. The data that is input into this conq)onent has a monetary amount (as 
do all accounting transactions) as well as the name of the account that is debited 
by the transaction and the name of the account that is credited by the transaction 
and the date of the transaction. The Dimensional Transformer component (100) is 
responsible for converting the name of the debit account to an index number in 
the debit dimension of the multi-dimensional data structure. It also is responsible 
for making this same conversion of the name of the credit accoxmt to an index in 
the credit dimension. Any additional dimensions are handled the same way by the 
Dimensional Transformer (100) component. 

The user is fi-ee to define his own definitions for the input data and is fi-ee to 
define the dimensions of the underlying data structure. The Dimensional 
Transformer (100) is configured with both definitions and how they are mapped 
to each other before the journal entries are entered. The definitions of the input 
data is given to the Dimensional Transformer (100) by one of the two input 
components, either the User Interface component (210) or the Bulk Loader 
component (220). The definition of the xmderlying multi-dimensional data 
structure is read in from an external file. 

The User Interface component (210) is used by a user that enters transactions 
through a Graphical User Interface (GUI) or window environment. The Bulk 
Loader component (220) first passes a definition of its input data to the 
Dimensional Transformer (100). It then begins to pass large numbers of journal 
entries, in bulk, to the Dimensional Transformer (100). 

The Star component (300) contains a structure that is isomorphic with the 
underlying data structure. For each dimension in the imderlying data structure 
there is a dimensional component that is managed by the Star component. 
Examples of these dimensional components are the Debit component (310), the 
Credit component (320), the Calendar Date component (330), and the 
Description component (340). Each of these dimensional components know how 
to convert input data into an index into the corresponding dimension in the 
underlying data structure. The Dimensional Transformer component (100) uses 



these dimensional conq)onents to actually perform the transformation of the 
individual dimension. 

The Data Module component (500) is the software entity that manages the 
underlying multi-dimensional data structure. It is a "plug-and-play" 
interchangeable component that can be replaced by other versions that allow the 
underlying data structxire to be implemented as a relational database or other 
alternative. 

The con:q)onents numbered 510, 520, and 530 are logically single conq)onents 
that use the multi-dimensional aspects of the Data Module component (500) to 
produce accounting reports. There are additional modules of this sort that satisfy 
all the practices recommended by the Generally Accepted Accounting Principles 
(GAAP). 

The Dicer component (580) is a module that allows the non-technical user to 
dynamically piece together dimensions in order to make an ad hoc analyitical 
study. The Slicer component (590) allows a user to choose between a number of 
pre- written analytical studies that have been developed by the user at an earlier 
time and that are stored with the Multi-dimensional Accounting Engine. 

DRAWING FIGURES 

• Figure Al 

o 2 Fact table 

o 6 Debit dimension table 

o 8 Credit dimension table 

o 10 Date dimension table 

o 12 Customer dimension table (optional) 

o 14 Description dimension table 

o 16 Supplier dimension table (optional) 

• Figure A2 

o 100 Dimensional Transformer component 
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o 210 User Interface component 

o 220 Bulk Loader component 

o 300 Star component 

o 310 Debit dimension component 

o 320 Credit dimension component 

o 330 Time dimension component 

o 340 Description dimension component 

o 500 Data Module component 

o 510 Ledger Account component 

o 520 Balance Sheet component 

o 530 Income Statement component 

o 580 Dicer component 

o 590 Slicer component 

Figure Bl 

o 1010 Configuring the Star step 

o 1020 User Interface configxiration step 

o 1030 Bulk Loader configuration step 

o 1 100 User Interface data input step 

o 1110 Bulk Loader data input step 

o 1120 Data transformation step 

o 1130 Debit dimension index resolution step 



o 1140 Data storage step 

• Figure B2 

o 21 10 Ledger account request step 

o 2120 Balance sheet request step 

o 2130 Income statement request step 

o 2140 Analysis request step 

o 2210 Ledger account generation step 

o 2220 Balance sheet generation step 

o 2230 Income statement generation step 

o 2240 Analysis generation step 

o 2300 Dimensional transformation step 

o 23 10 Debit dimension resolution step 

o 2400 Data retrieval step 

OPERATION - MAIN EMBODIMENT 

This invention is operated from two perspectives, the perspective of the user 
who enters or journals business transactions (figure Bl) and the perspective of the 
user who is using the invention to generate an accounting report or some other 
analytical study (Figure B2). 

Starting from the top of Figure Bl and proceeding downward, we see that the 
Multi-dimensional Accoxinting Engine starts up and reads in a complete definition 
of the structure of the imderlying database (1010). The Star component (300 in 
Figure A2) is constructed with all of the definitions that exist in the database. 
After this operation, the Multi-dimensional Accoxmting Engine is prepared to 
work with any module that attempts to enter business transactions. 

In (1020) and (1030) we see the data entry modules begin to insert 
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transactions. The User Interfece component (210 in Figure A2) and the Bulk 
Loader component (220 in Figure A2) begin by sending the structures of their 
input data and a mapping of how this data relates to the underlying database 
structure. Both input components have knowledge of the Star component and 
contain mappings from their input to the dimensions of the Star component. At 
this point in time the Dimension Transformer (100 in Figure A2) has all of the 
information necessary to convert the input to a multi-dimensional form. 

With all of the data definitions given to the Dimensional Transformer 
component, the input modules (210 and 220 in Figure A2) begin to send their 
transactions to the Dimensional Transformer component. This is shown in steps 
1 100 and 11 10 of Figure Bl. 

In step 1 120 of Figure Bl we see the Dimensional Transformer component 
convert the data from plain text to a fact record containing a set of dimensional 
indexes. 

In step 1 130 of Figure Bl we see the Dimensional Transformer con^onent 
taking the name of the debit accoimt as text and sending it to the Debit Dimension 
component (310 in Figure A2). This Debit Dimension component contains a 
mapping from the set of allowed text entries (the names of all the accounts) to the 
indexes that represent them in the debit dimension of the underlying database. The 
Debit Dimension component finds the proper index and retiims it to the 
Dimensional Transformer component then adds adds the index to the multi- 
dimensional fact record that it is building. 

The Dimensional Transformer component does this for each dimension in the 
database. When all the dimensions are resolved the Dimensional Transformer 
con^onent sends the new multi-dimensional fact record to the Data Module 
component (Figure 500 in Figure A2) where the fact record is added to the 
underlying data structure. At this point, the joumaling of new transactions in the 
multi-dimensional database is complete. 

At the top of that Figure B2, we see a set of boxes numbered 21 10, 2120, 
2130, and 2140. Each of these boxes represent the input of a user request for 
analytical data. The user goes through the graphical user interfece to build a 
request and then sends the request to an appropriate module within the Mulit- 
dimensional Accounting Engine (this is shown in boxes numbered 2210, 2220, 
2230, and 2240 of Figure B2). In box 2210 the request goes to component 510 of 
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Figure A2. In box 2220 the request goes to coiiqjonent 520 of A2. In box 2230 
the request goes to conq)onent 530 of Figure A2. In box 2240 the request goes to 
component 580 or conqjonent 590 of Figure A2. 

All of the requests are made in terms of user's text and are meaningless in 
terms of the underlying data structure which needs to be addressed in terms of 
dimension indexes rather than text. The requests are all sent to the Dimensional 
Transformer component (100 in Figure A2). In the Dimensional Transformer 
con^onent the textual requests are transformed by use of the Dimension software 
components (310, 320, 330, 390 in Figure A2) into dimensional indexes. This is 
shown in steps 2300 and 2310 of Figure B2. 

The Dimensional Transformer returns the request, in dimensional form, back 
to the requesting component which then sends the request to the Data Module 
component (500 in Figure A2). This is shown in step 2400 of Figure B2. The 
Data Module component accesses the underlying database and returns the results 
back to the requesting component where they are eventually retumed to the 
requesting user. 

ADVANTAGES 

From the description above, a number of advantages of this invention become 
evident: 

1 . All accounting reports can be created dynamically upon the user's request. 

2. Unlike a conventional accoxmting journal, which relates a transaction to a 
debit account and a credit account, a multi-dimensional data structure 
allows each entry to be stored with any amount of additional information, 
allowing the accountant to create an analysis tool that far exceeds the 
limites of today's current accoimting practices. 

3 . Within a multi-dimensional data structure the journal entries can readily by 
used for other analytical studies. 

4. Acoxmting reports can be limited to any range of dates that the user is 
interested in. 

5. Ledger accoimts are generated dynamically from the multi-dimensional data 
structure and have no physical existence of their own. This avoids a 
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duplication of data between the journal and the ledger accounts and the 
consistency problems that are inherent in duplicated data. 

6. Simplicity. The bookkeeping staff only has to enter the transactions into the 
Multi-dimensional Accounting Engine and the said Multi-dimensional 
Accounting Engine automatically performs all the other accoimting 
processes. 

CONCLUSION, RAMIFICATIONS, AND SCOPE 

Accordingly, the reader will see that the Multi-dimensional Accounting Engine 
gives businesses the ability to perform their accounting chores by simply 
joumaling the transaction. All the accounting work other then the actual 
joumaling itself is performed automatically by the Multi-dimensional Accounting 
Engine. 

The complete accounting practice, according to the General Accepted 
Accounting Principles (GAAP) can be performed effortlessly by the Multi- 
dimensional Accoxmting Engine and the underlying dimensional data structure. 
The only bookkeeping effort required is to journal the actual business 
transactions. 

The underlying multi-dimensional data structure can be used for other 
analytical reports which break the transactions down by customer demographics 
and other market factors. 



